Follow release reusables whose runner comes from _select-release-runner outputs - #8530

…er outputs

The runner-group allow-list dropped
pytorch/pytorch/.github/workflows/_build-triton-wheel-linux.yml, so every
build-wheel-{cuda,aarch64,rocm,xpu} job in "Build Triton wheels" queued
indefinitely with runner_group_name "" (e.g. pytorch/pytorch run 31811475863,
40 jobs stuck).

collect_release_workflow_paths used two disagreeing notions of "release
related". Entry detection propagates the rel- signal through a local reusable,
so a workflow that calls _select-release-runner.yml is discovered. Edge
traversal, though, only followed a `uses:` when the *calling job body* held an
inline rel- label. pytorch/pytorch#193378 split the triton build into
_build-triton-wheel-linux.yml, called as:

    build-wheel-cuda:
      needs: select-runner
      uses: ./.github/workflows/_build-triton-wheel-linux.yml
      with:
        runs_on: ${{ needs.select-runner.outputs.x86 }}

No inline label, so the edge was never taken and the reusable that actually
consumes the release runner never reached the allow-list. _binary-build-linux.yml
survived only because its generated caller still inlines the label in runs_on:.

Give both steps one definition of "runs on a release runner": an inline rel-
label, or a reference to the outputs of a job that calls a release-label
reusable. Sibling test/upload jobs still gate out, since they depend on the
build jobs rather than on the selector.

Dry-run against pytorch/pytorch over all seven target refs: 39 -> 40 entries,
the sole delta being _build-triton-wheel-linux.yml@refs/heads/main. Discovery on
the other six refs is unchanged, and per-ref discovery correctly omits the file
where it does not exist yet.